Preseed auth and trust settings for codex CLI.#9376
Conversation
liliwilson
changed the base branch from
graphite-base/9376
to
lili/remote-1502-initial-harness-setup-client-side-for-codex
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and posted feedback on this pull request. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
This PR seeds Codex auth and trust/config files for third-party harness runs, including API-key auth, trusted project entries, child repo trust, and a hardcoded regional OpenAI base URL.
Concerns
- Seeded
auth.jsonwrites the OpenAI API key through the generic JSON writer, so newly-created secret files may be world-readable depending on the process umask. - Auth key resolution does not match the terminal environment precedence, which can seed Codex with a different key than the one the launched process is meant to use.
openai_base_urlis overwritten unconditionally, which can break existing Codex configs or non-staging credentials.
Verdict
Found: 1 critical, 2 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
| ) | ||
| })?; | ||
|
|
||
| set_codex_openai_base_url(&mut doc, CODEX_OPENAI_BASE_URL); |
There was a problem hiding this comment.
openai_base_url on every Codex run, even for user env auth or existing logins, which can break custom/proxy/global configs; only set the US endpoint for the managed staging key or preserve a user-provided value.
There was a problem hiding this comment.
This is intentional for now, will be fixed in a future PR
There was a problem hiding this comment.
bro didn't even read the PR description smh
abhishekp106
left a comment
abhishekp106
left a comment
There was a problem hiding this comment.
Nice reverse engineering!
| ) | ||
| })?; | ||
|
|
||
| set_codex_openai_base_url(&mut doc, CODEX_OPENAI_BASE_URL); |
There was a problem hiding this comment.
bro didn't even read the PR description smh
| } | ||
|
|
||
| /// Return immediate subdirectories of `dir` that contain a `.git`. | ||
| fn find_child_git_repos(dir: &Path) -> Vec<std::path::PathBuf> { |
There was a problem hiding this comment.
Is this called synchronously? I suppose it's not that bad for the CLI to "hang" on a long filesystem operation, but since we spawn background tasks for network requests it could make sense here too
There was a problem hiding this comment.
It is -- for now, given that it's bounded to the number of repos we have in the environment and it's a shallow search, I'll keep it sync for simplicity, but we can def keep an eye on it if it causes any slowness!
## Description <!-- Please remember to add your design buddy onto the PR for review, if it contains any UI changes! --> This PR sets up the initial plumbing for supporting the Codex CLI with multi-harness. It follows the existing pattern for Claude Code and Gemini, implementing the `ThirdPartyHarness` trait for codex. Notable decisions: - We run the CLI with `--dangerously-bypass-approvals-and-sandbox` ([docs](https://developers.openai.com/codex/agent-approvals-security#run-without-approval-prompts)) - We provide the system prompt by writing to `AGENTS.override.md` ([docs](https://developers.openai.com/codex/guides/agents-md))—codex reads this first and recommends it for temporary instructions. It doesn't really matter yet which we use since these are running in a cloud agent context where we control the FS. - Codex, like Gemini, unfortunately doesn't support file input or redirecting stdin. We reuse the `$(cat prompt_file)` approach here for now. ## Testing <!-- How did you test this change? What automated tests did you add? If you didn't add any new tests, what's your justification for not adding any? If you're not sure whether you should add a test, check our testing policy: https://www.notion.so/warpdev/How-We-Code-at-Warp-257fe43d556e4b3c8dfd42f70004cc72#1f97825450504baa9c5fd87a737daa09 --> Tested E2E in downstream PR, #9376 Also confirmed that it picks up the system prompt instructions: <img width="1353" height="912" alt="image" src="https://github.com/user-attachments/assets/6665db5a-fbf3-427f-b95d-2e5c627f3865" /> ## Server API dependencies <!-- You may remove this section if your PR does not have any server dependencies. --> Relies on the support for Codex added to the server in warpdotdev/warp-server#10740 ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode --------- Co-authored-by: Oz <oz-agent@warp.dev>
liliwilson
force-pushed
the
lili/remote-1510-skip-trustauth-for-codex
branch
from
94d557b to
7437d85
Compare
Preseed auth and trust settings for codex CLI. (warpdotdev#9376)
2 participants
Description
This PR seeds the trust and auth config files for the codex harness, so that we don't get interactive dialogs re: trusting project folders or setting up auth when running in an autonomous cloud agent context. This is handled similarly to the Claude Code and Gemini settings configs.
Of note:
config.tomlfor both the working dir and any children git repos of that dir. This is relevant in the cloud agent case since we create aworkspace/dir and clone all environment repos into that dir, but we want to make sure they're trusted as well.ManagedSecrettype that can take in both an OpenAI API key and optionally a base URL to use it with.Testing
Added unit tests that cover setting up the settings files and making sure that we don't clobber any existing settings.
Tested manually after removing all of my local codex config to make sure that we don't get popups and can run queries correctly:
Demo.of.codex.initial.setup.mov
(Loom is having an incident but the show must go on, hence the QuickTime video)
Agent Mode